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METHODS AND APPARATUS FOR 
COLLECTING, STORING, PROCESSING 
AND USING NETWORK TRAFFIC DATA 

FIELD OF THE INVENTION 

The present invention is directed to the collection, 
storage, processing and use of data in computer networks^ 
and more specifically, to the collection, storage, processing 
and use of data relating to network traffic. 

BACKGROUND OF THE INVENTION 

The use of computer networks, and inter-connected 
groups of computer networks referred as intranets, continues 
to be on the increase. The World Wide Web (WWW), 
sometimes referred to as the Internet, is an example of a 
global system of inter-connected computer networks used 
for both business and personal pursuits. The increased use of 
intranets within individual businesses and the increased use 
of the Internet globally is due to the increased number of 
computer networks in existence and the ease with which 
data, e.g., messages and/or other information, can now be 
exchanged between computers located on inter-connected 
networks. 

FIG. 1 illustrates an intranet 10 implemented using known 
networking techniques and three local area networks 
(LANS) 20, 30, 40. The intranet 10 may be implemented 
within a business by linking together physically remote 
LANS 20, 30, 40. In the intranet 10, each of the first through 
third LANS 20, 30, 40 includes a plurality of computers (21, 
22, 23) (31, 32, 33) (41, 42, 43), respectively. The computers 
within each LAN 20, 30, 40 are coupled together by a data 
link, e.g., an Ethernet, 26, 36, 46, respectively. The first LAN 
20 is coupled to the second LAN 30 via a first router 18. 
Thus, the router 18 couples data links 26, 36 together. 
Similarly, the second LAN 30 is coupled to the third LAN 
30 via a second router 19 which couples data links 36 and 
46 together. 

As is known in the art, the transferring of data in the form 
of packets can involve processing by several layers which 
are implemented in both hardware and/or software at dif- 
ferent points in a network. A different protocol may be used 
at each level resulting in a protocol hierarchy. 

At the bottom of the protocol hierarchy is the network 
layer protocol. One or more application layer protocols are 
located above the network layer protocol. In the present 
application, when describing a protocol associated with a 
data packet, the protocol associated with the packet will be 
described in terms of the protocols and layers associated 
therewith. 

For example, the annotation: 

<network-layer>/<application-Iayer 1>/ . . 
N> 



10 



15 



20 



25 



30 



35 



50 



. / opplication- layer 



is used to describe the protocol hierarchy of the top-level 
(application-layer N) protocol. As another example, con- 
sider a packet which uses the SNMP (Simple Network 
Management Protocol) running over UDP (User Datagram 
Protocol), running on an IP (Internet Protocol) network- 
layer protocol. Such a packet would be described herein as 
an IP/UDP/SNMP packet. 

As networks have grown in size and the volume of data 
being passed over networks has increased, system adminis- 
trators have been faced with the job of planning and main- 
taining networks of ever increasing size and complexity. 

Network traffic information can be used when trouble- 
shooting problems on an existing network. It can also be 
used when controlling routing on a system with alternative 
routing paths. In addition, information on existing or chang- 



55 



60 



65 



ing network traffic trends is useful when decisions on 
upgrading or expanding service are being made. Thus, 
information on network traffic is useful both when main- 
taining an existing network and when planning modifica- 
tions and/or additions to a network. Given the usefulness of 
network traffic information, system administrators have rec- 
ognized the need for methods and apparatus for monitoring 
network activity, e.g., data traffic. 

Because intranets often encompass geographically remote 
systems and/or networks, remote monitoring of network 
traffic is often desirable. 

In order to facilitate the monitoring of network activity, 
remote monitoring (RMON) devices, often called monitors 
or probes, are sometimes used. These devices often serve as 
agents of a central network management station. Often the 
remote probes are stand-alone devices which include inter- 
nal resources, e.g., data storage and processing resources, 
used to collect, process and forward, e.g., to the network 
management system, information on packets being passed 
over the network segment being monitored. In other cases, 
probes are built into devices such as a routers and bridges. 
In such cases, the available data processing and storage 
resources are often shared between a device's primary 
functions and its secondary traffic monitoring and reporting 
functions. In order to manage an intranet or other network 
comprising multiple segments many probes may be used, 
e.g., one per each network segment to be monitored. 

Network traffic data collected by a probe is normally 
stored internally within the probe until, e.g., being provided 
to a network management station. The network traffic data is 
usually stored in a table sometimes referred to as a man- 
agement information base (MIB). Recently, RMON2 MIB 
standards have been set by the Internet Engineering Task 
Force (IETF) which increase the types of network traffic that 
can be monitored, the number of ways network traffic can be 
counted, and also the number of data formats which can be 
used for storing collected data. RMON2 tables may include 
a variety of network traffic data including information on 
network traffic which occurs on layers 3 through 7 of the 
Open Systems Interconnect (OSI) model. The particular 
network traffic information which is available from a probe 
will depend on which data table the probe implements and 
the counting method employed. 

Currently, four different RMON2 matrix (or conversation) 
table types are possible: alMatrix, alMatrixTopN, nlMatrix, 
and nlMatrixTopN. 

Complicating matters, alMatrixTopN tables support two 
counting modes of operation which affect the manner in 
which the counting of packets and bytes is performed at the 
various protocol layers. The first of these counting modes 
will be referred to herein as all count mode. In this mode, 
each monitored packet increments the counters for all the 
protocol layers used in the packet. For example, an IP/TCP/ 
HTTP packet would increment the packet and byte counters 
for the IP, TCP and HTTP protocols. The second counting 
mode will be referred to herein as terminal count mode. In 
this mode, each monitored packet increments only the 
counter of the "highest-layer" protocol in the packet. For 
example, an IP/TCP/HTTP packet would increment the 
packet and byte counters for only the HTTP protocol. Note 
that the terminal count mode may only be used with the 
alMatrixTopN table. However, all count mode can be used 
with all the RMON2 tables discussed above including the 
alMatrixTopN table. 

Accordingly, probes may now collect and store data in 
tables corresponding to any one of five different RMON2 
formats. The five different RMON2 table possibilities are 
identified herein as alMatrixTopN(Terminal Count Mode), 
alMatrixTopN(All Count Mode), alMatrix, nlMatrix and 
nlMatrixTopN tables. 

Numerous distinctions exist between the various types of 
tables that may be supported by an RMON2 probe. 
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Network-layer (nl) tables, e.g., nlMatrix, and nlMatrix- the individual probe's available resources, and the MIB 

TopN tables, count only those protocols which are deemed format implemented by the individual probes 
to be network-layer protocols. Network-layer protocols are The numerous variations in data counting methods and 

the protocols which are used to provide the transport-layer monitored protocol layer information discussed above can 
services as per the well known ISO OSI 7-layer protocol 5 cause network traffic data collected from probes to be 

model, and include, for example, such protocols as IP, IPX, difficult to compare, process and display in a manner that can 

DECNET, NetBEUI and NetBIOS among others. No child- be easil y understood by a human. 

protocols of the network-layer protocols are counted in One solution to the problem of different data tables, being 

network-layer tables. supported by different probes in a network, is to use only 

Application-layer (al) tables, e.g., alMatrixTopN P r ° bes wnich provide data in the same format. 
(Terminal Count Mode), alMatrixTopN(All Count Mode), 10 y nf ° rtunat ely, this approach tends to be costly and often 

and alMatrix tables, count any protocol that is transport layer m ™} VQS , replacing existing probes, adding new probes, 

or above, provided the probe knows how to decode the ! I ^ti!^3S Iir0 ^f S l^^ 11 ** 1 ?fl in .? M1,C toc? 1 ^^^^ 

protocol. This includes, e*g., everything from IP through to c %TjJ n T™t T ^JT^ ^ ^ 

provide, by counting child-protocols of the supported While the recent addition of RMON2 support for includ- 

network-layer protocols. in g information about child protocols in at least some data 

In addition to the different types of protocol data that will tables, greatly increases the level of detailed information that 
be monitored depending on whether a network layer (nl) or 20 can be collected regarding network traffic, it has lead to 

application layer (al) table is being supported, the method of increases in probe data storage and processing requirements, 

counting data will vary depending on the supported table As the volume of network and intranet activity continues to 

type. increase into the Gigabytes/sec range, space required to store 

The alMatrix and nlMatrix tables monitor conversations detailed network traffic information for extended periods of 
which occur in the network, and keep count of the total 25 time can become significant. While the data storage require- 

number of bytes and packets seen for each conversation for me nts for a probe maintaining network traffic data can be 

each monitored protocol since the probe was turned on. If S1 g n ificant, the data storage requirements for a management 

the probe has been reset since it was turned on, then the s . ystem stonn S data obtained from several probes is many 

counters store the number of bytes and packets seen since tin J5 s Skater. 

the last time the probe was reset. These kinds of counters , k " ow , n technique for limiting the growth of a net- 

will be refereed to herein as absolute counters. The entries 30 WOr k . traffic databas e is referred to as data aging. Data aging 

in alMatrix and nlMatrix tables are ordered by address and ™ volvcs periodically scanning the stored data and, during 

protocol. tDe s 0 * 11 ' data records that are older than certain preselected 

The alMatrixTopN and nlMatrixTopN tables also monitor age Iimits ^ ™ d ™ d 8 et c °mbined, e.g., added together, 

all conversations which occur in the network, and also keep l ? create an addltlonal of da t a records of lower resolution 
count of the number of bytes and packets seen for each 35 than the records used to create the additional set. The records 

conversation. However, there are several differences tjsed to create the lower resolution set of data records are 

MatrixTopN tables must be configured by the user or by a . d ^ leted from the on & n * 1 database. When this technique 

client program, and are configured to have a maximum 15 u , sed ' l . here normall y multiple age limits set up, 

number of entries and a time interval for which the table will resulting in multiple data sets corresponding to different 
be generated. Once configured, the probe will perform the 40 n ° D -° verla PP m g lime periods. In such a system, the older 

following steps until the MatrixTopN table is destroyed the data ref 0 ^ become the lower the resolution of those 

(either by a request from the user or client program, or by the reco , wUI Hence less disk s P ace fe retired to store 

probe being turned off)- records corresponding to a fixed period of time, the longer 

1. Monitor the conversations in the network, counting the " S^^J^ 1 ^ 0 ^ ^Tf • u 
packets and bytes seen over the specified time interval. 45 e J/^S^L^ ^ f < ^ ^ ~ V " 

o rwo.u • . i- i j . tl 45 eral disadvantages, both from an implementation standpoint 

2. Once the time interval is reached, then generate a tab e and from thc standpoint of a human system administrator 
of he top N conversations seen in the network. This attempting to use the stored network traffic information. 

™^ 3 nH n ^iH etn n e th y ?f m* 1 " ( ° f CUe ^ Fr0m an ^mentation standpoint, the known system 

program), and is held until the next table is generated, has the distinct disadvantage of requiring double buffering 

TmI^ m P a Ki S C K reD U abl K Th u ° rd T S in , 50 0f the data while the a S iD g P rocess * bein S Performed. Such 

a MatrixTopN table may be either by the number of double buffering is required so that accessing the data during 

packets seen, or by the number of bytes seen. aging will still give the resuhs Give * ma( the size * 

3. Go back to step 1. the database to be aged can be quite substantial, double 
As MatrixTopN tables monitor the number of packets and buffering presents obvious hardware disadvantages. From an 

bytes seen over the specified time interval, with the counters 55 implementation standpoint the known aging process also has 

being effectively reset each time a new table of the top N the disadvantage of placing significant periodic demands for 

conversations is generated, the counters generated by processing resources that can interfere, e.g., slow or delay, 

MatrixTopN tables are referred to herein as delta counters. other processing tasks performed by a management station^ 

Because intranets and the networks which comprise intra- while the aging operation is being performed, 
nets are frequently implemented and modified over a period The known data aging process results in multiple, non- 

of time, a plurality of different probes, often supporting 60 overlapping data sets of differing resolutions corresponding 

different data traffic table formats, will frequently be to different time periods. From a human standpoint, this 

encountered in the same network. In some cases, a probe makes it difficult to review and compare data sets to detect, 

may have insufficient processing and data storage resources e.g., network traffic problems, since the data sets correspond 

to support all but the least resource intensive data table to different time periods. 

format, e.g., an nlMatrix table. Accordingly, the information 65 in view of the above discussion, it becomes apparent that 

included in traffic data tables of probes may vary from probe there is a need for new and improved methods and apparatus 

to probe depending on the particular protocols monitored, for collecting and handling network traffic data from probes. 
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In particular, there is a need for methods of collecting 
network traffic data that minimize the number of different 
data formats and data tables which must be processed. In 
addition, there is a need for new methods and apparatus for 
processing data received in differing formats to produce a 5 
database of network traffic data which can easily be accessed 
by other applications and/or presented to a human admin- 
istrator in a manner that allows for easy comparison and 
presentation of traffic data monitored on various network 
segments. 

In addition, there is a need for methods and apparatus 10 
which are capable of limiting the growth of databases, e.g., 
network traffic databases, over time. It is desirable that the 
methods and apparatus allow for accurate access to the 
database at all times, once it is created. It is also desirable 
that the database methods not require double buffering of the 15 
data included in the database to support such access. In 
addition, if data sets of different resolutions are included in 
the database, it is desirable that the lower resolution data sets 
incorporate the information found in the higher resolution 
data sets and overlap for at least some period of time. 20 

Data from different probes corresponding to a particular 
time period may not be received precisely at the same time 
by a monitoring device, e.g., due to network transmission 
delays, etc. Accordingly, it is also desirable that methods and 
apparatus for receiving and storing network traffic informa- 1S 
tion be capable of compensating for such delays so that 
received network traffic data is stored and presented in a 
manner that accurately reflects the traffic in the time period 
that was monitored and not the time at which the traffic data 
was received by the monitoring station. 

In addition to the above features, it is desirable that new 30 
methods of collecting, processing and storing network traffic 
data be compatible with existing probe data formats. It is 
also desirable that the new methods and apparatus be 
capable of being used with, or adapted to being used with, 
probe data formats that may be supported in the future. 35 

In particular, it is desirable that that at least some new 
methods and apparatus be capable of working with network 
traffic data in a plurality of table and count formats including 
various RMON2 tables. It is also desirable that any such 
method and/or apparatus not require a specific one of the 40 
RMON2 tables to be used by a probe which would result in 
a constraint on RMON2 probe selection and probe resource 
requirements. 

In view of the above, it is apparent that there remains 
considerable room for improvement in how network traffic 45 
data is collected, stored, processed and presented to network 
administrators and other individuals responsible for the 
design, maintenance and upgrading of networks and intra- 
nets. 

SUMMARY OF THE PRESENT INVENTION 50 

The present invention is directed to methods and appa- 
ratus for collecting, storing, processing and using data, e.g., 
network traffic data, in computer networks. 

Several embodiments of the present invention are directed 
to dealing with the difficulties associated with collecting and 55 
processing network traffic data. As discussed above, one of 
the major problems encountered with collecting and pro- 
cessing network traffic data is the numerous different count- 
ing techniques and data table storage formats that may be 
used by various probes in the same system. 60 

In order to provide a high degree of detailed information 
for subsequent applications, attempts are made by the 
method of the present invention to collect application layer 
traffic data as well as network layer traffic data. 

To reduce problems due to different counting techniques 65 
and data table formats, the present invention processes 
collected network traffic data, as required, to place it into a 
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common data format. The common data format is selected to 
provide a maximum degree of information in a format that 
is easy to use, e.g., by database generation and graphing 
application. 

From a user standpoint, it was determined that, in at least 
one embodiment of the invention, it was desirable that the 
common data format include delta count values as opposed 
to absolute count values and that application layer informa- 
tion be presented in terminal count mode as opposed to all 
count mode. 

In order to reduce the amount of processing required to 
put the data in the desired common format, and the tempo- 
rary data storage requirements associated with such 
processing, the system of the present invention controls 
network traffic data probes to provide data in a format that 
is as close to the desired format as possible, given an 
individual probe's capabilities. 

One specific embodiment of the present invention is 
directed to the use of RMON2 probes and RMON2 data 
tables. 

In one such embodiment, to minimize the amount of data 
processing required to put a probe's network traffic data into 
the common format used by a management system of the 
present invention, and to maximize the amount of informa- 
tion collected, network data is obtained from a probe using 
one of the available RMON2 table formats. In accordance 
with the present invention the RMON2 format is selected in 
the following order of preference: alMatrixTopN(Terminal 
Mode), alMatrixTopN(AllMode), alMatrix, nlMatrixTopN 
and nlMatrix. 

RMON2 alMatrixTopN(Terminal Mode) data tables sat- 
isfy the format requirements used in the present invention 
and therefore do not require conversion operation to be 
performed. In addition RMON2 alMatrixTopN(Terminal 
Mode) data tables include both application layer and net- 
work layer data. For these reasons, the RMON2 
alMatrixTopN(Terminal Mode) data table is the most pre- 
ferred of the RMON2 tables in the above discussed embodi- 
ment. 

Once network traffic data is collected and placed in a 
common format, it is ready for use in generating displays 
and/or network traffic databases. 

In one particular embodiment of the present invention, the 
network traffic data, in the common data format, is stored in 
a network traffic database to allow for future analysis such 
as baselining and troubleshooting. 

The known database aging process is avoided by the 
system of the present, by creating and maintaining a data- 
base that includes multiple parallel sets of network traffic 
data at different resolutions. In accordance with the database 
generation and maintenance routine of the present invention, 
a data set for each different resolution is stored in a first-in, 
first-out (FIFO) data structure. The oldest records in the 
FIFO data structure are overwritten when there is no longer 
any unused storage space available for storing the records of 
the resolution to which the data structure corresponds. 

Because the network traffic database of the present inven- 
tion is not aged, the periodic processor loading associated 
with aging of databases is avoided. In addition, the need to 
double buffer the database data during an aging process is 
eliminated since no aging is performed. 

The parallel database routines of the present invention 
also have the advantage of being well suited to a multipro- 
cessor environment since each data set can be maintained 
and updated independently. 

In the databases of the present invention, the database 
records at the different resolutions overlap covering the 
same time period. This makes it relatively easy for a system 
administrator to review database records corresponding to 
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the same time period at different resolutions. This can The second LAN 130 is coupled to the third LAN 130 via 

facilitate a system administrator's attempts to identify net- a third router 19 which couples data links 36 and 46 together 

work traffic problems and/or trends without the need to Data links 26, 36 and 46 are network segments within the 

perform complicated processing when comparing or switch- intranet 200. In order to obtain information on each of the 

mg between data at different resolutions. 5 network segments 26, 36, 46 probes 127, 137, 147 are 

In addition to the above described features, many other included in each of the first through third LANs, respec- 

features and embodiments of the present invention are tively. Each probe is coupled to the data link, e.g., Ethernet, 

described in detail below. which is included in the LAN in which the probe resides! 

- Because the first probe 127 is coupled to the first Ethernet 26 

BRIEF DESCRIPTION OF THE DRAWINGS it can collect information about traffic on the network 

FIG. 1 is a block diagram of a known intranet arrange- 10 ^ g T, Dt 26 S ™ la ! 1 * the second and third Piobts 137, 147 

merit are able to collect information about traffic on the network 

t*" * ' te >»f"' """ir K " ^^^mom^mS)."*™* 0 * <lk 

MG. 3 is a diagram of a protocol hierarchy used in various The ornhe* 127 1T7 147 ma « ™i,wi- ' 

examples drai^pH herein prooes 1Z7, 1,57, 147 may include memory, a 

examples discussed herein. processor, an I/O interface device and a mass storage device, 

MG. 4A is a flow chart of a management system initial- such as a disk drive. In one embodiment, probes 127 137 

ization routine implemented in accordance with the present 147 are implemented using known network traffic data 

invention. 20 probes. 

FIG 4B is an exemplary probe information/data table In accordance with the present invention, each of the 

created by executing the initialization routine illustrated in probes 127, 137, 147 is coupled to a management station 150 

FIG. 4A. which also forms part of the intranet 200. The management 

FIG. 5 is a diagram showing the processing of network station 150 includes a display device 152, one or more 

conversation data in accordance with one exemplary 2 5 cenl ral processing units (CPUs) 154, 155, a keyboard 156, 

embodiment of the present invention. a mass storage device 158 for storing, e.g., a data base, and' 

FIG. 6A illustrates a method of collecting network traffic memory 162 which are coupled together by a bus 163. The 

data from probes and converting the collected data into a mass storage device 158 may be, e.g., a disk drive or array 

common data format. of drives. In the embodiment illustrated in FIG. 2, two CPUs 

FIG. 6B illustrates the conversion of various RMON2 30 J, 54 ' 155 . ca P able of operating in parallel are shown, 

data tables into the common data format used in accordance However, in many embodiments, a single CPU 154 is used 

with various embodiments of the present invention on a time snared Dasis > e *g> t0 perform database generation 

FIG. 7 is a block diagram illustrating the generation of a an ^ maintenance operations 

network traffic database including parallel sets of data of 163 ^P" 5 the discussed management station 

differing resolutions 35 components to an input/output (I/O) interface 160 used to 

FIG. 8 is a flow chart illustrating a method of the present 

Ji% a « M rt : llus i ratin S a network traffic station 150 as a function of various routines stored in the 

database includmg parallel sets of network traffic mforrna- memory 162. The use of one or both of the CPUs in 

tion stored at different resolutions. controlling the operation of the management station 150, 

DETAILED DESCRIPTION depends on the implemented operating system. For exem- 

, , . 45 plary purposes it will be assumed that only CPU 154 is used 

As discussed above, the present invention relates to to control operation of the management station 150 

methods and apparatus which can be used collect, store, and The routines, stored in the memory 162, include initial- 

n£wn* if* T^* 8 ^ C ' V ™*° n routines 171 ' data collection and conversion routines 

network or mtranet. It is also directed to methods of pre- 164, parallel data set generation routines 166, and 

seating network traffic data in a format that can be easily 5Q processing/filtering/display routines 168. T^e various rou- 

understood by a person, e.g., an individual responsible for tines may be implemented as computer programs. In addi- 

managing the computer network or networks being moni- tion to the routines 171, 164, 166, 168, the memory 169 may 

tored * include probe information and data tables received from the 

Referring now to FIG. 2, there is illustrated an intranet probes 127, 137 and 147. 

200 implemented in accordance with one embodiment of the The memory 162 may also include a buffer 173 for 

present invention. Various elements of the intranet 200 temporarily storing data tables converted to the common 

which are the same as, or similar to, the known intranet 10, format of the present invention. The collected probe data 

are identified using the same reference numerals used in stored in the buffer 173 is processed by the CPU 154 under 

mGt . control of routines 164, 166, 168 and stored in a network 

As illustrated, the intranet 200 comprises first through traffic information database located on the storage device 
third LANS 120, 130, 140 each of which includes a plurality 60 158 as will be discussed below 

of computers (21, 22, 23) (31, 32, 33) (41, 42, 43), respec- The keyboard 156 can be used for inputting queries 

lively. The computers within each LAN 120, 130, 140 are regarding network traffic information. Charts and statistics 

coupled together by a data link, e.g., an Ethernet, 26, 36, 46, regarding network traffic information are generated by the 

?T^Z T y -' t firSt LAN 120 is C0upled t0 the SCC0Dd CPU 154 in response to such queries using the data included 
LAN 130 viaa first router 17 which couples data links 26, 65 in the network traffic database. The charts and statistics are 

7 5?£ er ' • Thc firSt LAN 120 fe also coupled t0 lhe third displayed on the display device 152 and/or printed on a 

LAN 140 via a second router 18. printer 170 coupled to the management station 150. 
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form nf 3 a ^'inf \° ? empl t ry Pr0t0C °l ^ ierarchy in , the lhe COmmon data fonnat shoul <* delude application layer 

form of a tree 301 which may be retrieved from one of the protocol information when available. In addition it was 

probes 127, 137, 147 for a monitored conversation between decided that it was more useful to have the data represented 

two devices included in the intranet 200. The hierarchy in terminal count mode, as opposed to all count mode 

illustrated in FIG. 3 will be used in the discussion which 5 Unfortunately, the only RMON2 table which satisfies the 

follows to illustrate various points. Note that, while a probe ? bove discussed criterion selected for a common data format 

127, 137, 147 may support many thousands of protocols, ^ tne alMatrixTopN (terminal count mode) table. Because 

only those protocols which have been seen for a particular nlMatrix and nlMatrixTopN tables only include network 

conversation will be stored in the data table or tables la ^ r traffic data » these two ta b^s are considered the least 

supported by the probe and thus will be the only protocols us f . and are not used unless the probe from which the data 

which may be retrieved by the management station 150 from 10 B b f. m g. obta »ned does not support one of the three possible 

the probe for that conversation. application layer tables. 

In the FIG. 3, diagram, the protocols shown are IP aoSbrt'S^ 

(Internet Protocol), UDP (User DaLgram Protocol) SNMP ^.^^ 

(Simple Network Management Protocol), TCP from a pausing one of the available table forma ™ 

Z^Z\^ V m ?T °t C0 Pt F 7 ( p ile T rf r ^^nnatutilized'being selected in the follo^M 

Protocol) and HTTP (Hyper-Text Transfer Protocol— also preference: alMatrixTopN(Terminal Mode), alMatrixTonN 

sometimes referred to as WWW (World Wide Web) traffic). (AllMode), alMatrix, nlMatrixTopN and nlMatrix. 

The tree 100 has been divided into two halves: the ^ discussed above, an alMatrixTopN(Terminal Mode) 

network-layer protocol 303 and the application-layer proto- table bas the advantage of requiring no format conversion 

cols 305. This division will be used in later examples. 20 operations. 

The conversation for which the tree has been generated is ™ C a ^ atr i? To P N (AllMode) table requires a single con- 

a conversation between two devices e.g., computers A and B VCr ?° D operatl . on ' Le - an . aU mode to terminal count 

21, 22, using the IP network-layer protocol. ? £™t ^^^V™' ? ^Ti * in the C ° mm ° n 

Th^TP/irnn * i • u . . JL L . . tormat. Unlike absolute count to delta count conversion 

The IP/UDP protocol is shown in a dotted box— this is to operations, as will be discussed below, terminal count con- 
represent that, while the IP/UDP/SNMP packets were moni- * version operations can be performed fwithom the S!o™ 
tored by the probe 127, the probe 127 had the IP/UDP the previously received data table. Accordingly 
protocol turned off. This is a feature of RMON2, (the ability alMatrixTopN(AllMode) tables can be converted to the 
to turn off the monitoring of protocols), and means that any common format with a minimum of processing and memory 
pure IP/UDP packets would not be counted. Thus, a count of requirements. 

any pure IP/UDP packets on the network segment 26 would 30 The alMatrix table is less desirable than the other appli- 

not be supplied by the probe to the management station 150 cation layer tables because it requires two conversion opera- 

on retrieval of the network traffic data from the probe 127. tions to place it in the common format. Furthermore, one of 

However, child protocols of IP/UDP (such as IP/UDP/ the conversion operations requires buffering of a retrieved 

SNMP) would continue to be counted and supplied to the data table for the duration of the data measurement interval 

management station 150 from the probe 127. 35 thereby requiring more memory than is required to put the 

As IP/UDP is not being monitored by the probe, we can alMatrixTopN table in the common data format, 
describe this tree using the following format: Identification of the probes which are coupled to the 
IP management system 150, the data tables they support, and 
IP/UDP/SNMP tne s^ti 00 of data table to be used with each probe 
IPyTCP 40 occur during execution, by CPU 154, of a management 
IP/TCP/FTP Stati0D initiali2auon routine 300. The routine 300 is one of 
iP/TrP/HT-TP the initializ ation routines included in memory segment 171. 
a !r j u , ■ , . Operation of the management station 150 of the present 
As diseased above, networks may include a variety of invention will now be discussed with regard to the initial- 
probes 127 137, 147 with differing capabilities and differ- ization routine 300 shown in FIG. 4A. The initialization 
ing network data table formats. In accordance with the 45 rout ine 300 is performed by the management station eg 
present invention the management station 150 collects and when the station is powered up or reset. The initialization 
processes network traffic data from the probes 127, 137, 147 routine 300 begins in step 302 wherein the initialization 
included in the network. In order to simplify subsequent data routines 171 is executed by the CPU 154 
processing operations, the network traffic data received from In step 104, the management system 150 detects the 
the probes is processed to place it in a consistent format that 50 probes 127, 137, 147 which are coupled to the system 150 
can be used to support queries, storage, and displaying of The detection of the probes may be done, as known in the 
network traffic data in a format that is easy process and art, by transmitting a signal querying for a response from 
understand. By converting network traffic data into a con- probes which are present. 

sistent format at an early stage, processing components and Once a probe is detected, the initialization routine deter- 

modules, e.g., the parallel data set generation routines 166 55 mines the network traffic table format that is to be used with 

and processing/filtenng/display routines 168, can be isolated the detected probe and stores that information in memory for 

from the complexities associated with varying network future use, e.g., in determining what if any format conver- 

traffic data formats encountered from probe to probe. sions need to be performed on data obtained from the probe 

Hie inventors of the present application recognized that, For each detected probe 127, 137, 147 the initialization 

tor most purposes, what is of interest is the network traffic process proceeds through steps 306 through 322. The path 

during a specific time interval and not the total amount of 60 taken through these steps determines which table format will 

tramc monitored from the time a probe is turned on. be used with the identified probe 

Accordingly, in determining the common format into which In step 306 a determination is made as to whether or not 
network traffic data should be placed, it was decided that a the probe being initialized supports application layer tables 
delta counting as opposed to absolute counting, technique i.e., if the probe has alMatrix capability. In one embodiment 
should be used. In addition, it was decided that, for maxi- 65 alMatrix support is determined by querying a probeCapa- 
mum flexibility, it was useful to obtain as much detail about bilities object supported by the detected probe and monitor- 
network traffic as possible. Accordingly, it was decided that ing the probe's response 
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It in step 306 it is determined that the probe includes If in sten Ml it ic Hpt*>rm™H th.t ™ • * . 

alMatrix support, operation proceeds to s«e P p 308. In £ inS&Sto?SS TSTxU 
^™,£3^%^l*^^ pa **- ,oa ?* toWaUzation routine » P .topp5pSKKiSS& £ 
£J«n ?h . ? T* ? mal ™° de f 5 "^- « next power up or resetting of the management S 150 

,h.; dele 7 med ^:8 ' . rec , e of a frorn 5 An exemplary probe information/data fcbte 16 i created in 

the probe, that creation of the desired alMatnxTopN table 5 memory 150 via execution of the initialization I routine is 
was ^uccessfu , operation proceeds to step 312 In step 312, illustrated in FIG. 4B. Each detected 137 147 
probe information m memory is updated to include an entry identified in the table 169 as well as the fh™ » nf thJ h Jf 

W ,h ?»J ^ atnxTopNCTerminal Count Mode) format. collecting network traffic data. Note that the table 169 
^fl h ,^ SU0Cess&1 u P d f"g °?™m°ry in step 312 to 10 includes temporary data table storage space used for storing 

™h ^ T 861106 , and vf f 6 f0m,at ° f ,hE deteCted data tables ^ 35 P art of the f °™t cSnverrion opeS 

probe which wasjust initialized, operation proceeds to step discussed below. Note also that retrieved alMatrixTopN 

, • _ „ . tabl es and nlMatrixTopN tables need not be stored for use in 

It, in step 310 it was determined that terminal alMatrix- subsequent table format conversion operations since these 

TopN table creation was unsuccessful, operation proceeds to 15 tables are retrieved from the probe in the desired delta count 

step 314 instead of 312. In step 314 the management system format. 

150 signals the probe being initialized to create an alMa- 0nce tne management system 150 is initialized, 

trixTopN table using all count mode (as opposed to terminal collection, processing and storage of network data com ' 

count mode) counting. mences. FIG. 5 illustrates the collection, processing, storage 

If, in step 316, it is determined that all count Mode and di fP la y of network traffic data in accordance with an 
alMatrixTopN table creation was successful, e.g. by mod- 20 ex ? mp c , < !? , embodiment of the present invention, 

taring for a signal from the probe being initialized operation „ h • i, . i' b f §£° U ? of • netw , orks ™> 13 °. 140. from 

proceeds to step 318. In step 318, probe information in ™2 ° rk ^Su? "? S^SS* " e S eneraU y «P»- 

memory is updated to include an ent^y on the probe being £hi5? " "f roup b y the , bl °<* 502. The probes 127, 137, 147 

initialized and to indicate that the probe's daw is in 1 f each or De,work se 8 ment serve as 

and data table format of the detected probe which was just probe 127, 137, 147 periodically in response to requests 

U^^T?* 1 ?? 66 * 10 ^? 2 ?^ , - ^ management Ltion 150, for ^information lie 

If in step 316, it is determined that all Mode alMatnx- arrows, leading from the probes 127, 137, 147 to the data 
IZ ™ ^^n^^^^loPfration proceeds to 30 collection and conversion step 504 of (he management 

imrffltpH t'fi TS ' ? fT L m mem0ry * Station 150 * re P resent me P assin e of the requested network 
updated to include an entry on the probe being initialized traffic data to the management station 150 

and to indicate that the probe's data is in alMatrix format. Within the management station 150, there are several 

With the successful updating of memory m step 320 lo processing blocks 504, 508, 515 which are used to represent 

™£ j£ , a " !f blC f ° rmat ° f the detect£d 35 the va ™us processing operations performed by the man- 

probe which was just initialized, operation proceeds to step agement station 150. In addition, there are several blocks, 

• a „ ,„,. ., . . , ... . . e.g., blocks 506, 510 and 152 which are used to illustrate the' 

1 m step 306, it is determined that the probe being input and output data associated with the various processing 
initialized does not support alMatrix tables, a network layer operations processing 

bC f k ?n d f ° r ^,1° t UCb a ?*• 0peration 40 1)16 data coUection and conversion step 504 represents 
omste f 3 ,2 6tos ' e P324wherem the management 40 data collection and formatting operations which are imple- 
station 150 signals the probe being initialized to create an mented using computer software, in the form of the data 

in a ^5?< • .• ■ ^ L L collection and conversion routines 164, to control the CPU 

In step 326, a determination is made as to whether or not 154. 

creation of the nlMatrixTopN table was successful. In accordance with the processing performed in the data 

If, in step 326, it is (determined that nlMatrixTopN table 45 collection and conversion module 504, network traffic data 

creation was successful, e g. by monitoring for a signal is collected at periodic intervals from each of the detected 

from the probe ^emg imtialized, operation proceeds to step probes and converted, in accordance with the present 

328. In step 328, probe information m memory is updated to invention, into the preselected common format discussed 

include an entry on the probe being initialized and to above. The processing performed by the module 504 will be 

indicate that the probe s data is in nlMatrixTopN format. 50 discussed in greater detail with regard to FIG 6 

With the successful updating of memory in step 328 to The output of the data collection and formatting step 504 

reflect the presence and data table format of the detected is a set of network traffic data 506 which includes data from 

probe which was just initialized, operation proceeds to step various probes that has been converted into the common 

ifi„ct„i« v j. • ., j ,w • data forma' of the present invention. The network traffic data 

x vr . P ' lS detenn,n6d that a " Mode nIMatnx- JS 506 represents data from multiple probes collected during 

TopN table creation was unsuccessful, operation proceeds to one periodic data collection operation involving the collec- 

step AJU. in step 330, probe information in memory is tion of data from probes 127, 137, 147. The set of network 

^ritin*-^,! It entr l ° D th ! Pf0be b f?? 8 ? ni !. ialized ,raffic data 506 «» 85 the in put to a network traffic data 
and to indicate that the probe's data is m nIMatnx format. set generation and maintenance module 508. As wiU be 
Za?n?£ successful updating of memory in step 330 to discussed in detail below, the data set generation and main- 
reflect the presence and data table format of the detected <* tenance module 508 is responsible for generating multiple 
probe which was just initialized, operation proceeds to step parallel sets of data which overlap in time but differ in terms 

. , . ,. . , of the resolution at which the network traffic data is stored 

In step 322 a determination is made as to whether any in each data set. The group of data sets generated by (he 

probes detected in step 304 remain uninitialized. If there is module 508 represent a network traffic database 510 extend? 

another probe to be initialized, operation proceeds once «s ing in time over multiple periodic data collection cycles. 

again to step 306 wherein initialization of the next probe The data in network traffic database 510 can be accessed, 

glDS " e.g., in response to queries, processed, filtered and displayed 
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nJwnrt ,„m embod , in ? e P t ' a Clre j e 1?» d 'splay of If in step 608 an nlMatrix table is received the absolute 

FIG. 6A illustrates a method 600 corresponding, in one * formed since apphcation layer 

exemplary embodiment of the invention, to^e dafa collec- 20 nlM.t 7 ^ 1°° * D °! aV3ll * ble fr ° m the rCCeived 

tion and conversion step 504. The routine 600 is executed ™ rixT °pN table. In step 608 when an nlMatrixTopN 

periodically, e.g., every 30 minutes by the CPU 154 As u B received ' operation proceeds directly to step 614 

illustrated, the data collection and conversion routine 600 wh ^ rein lhe received data table is stored in the buffer 173. 

starts in step 602. During this step, the routine 600 is , m stG P 6 \ 4 > °P eralion proceeds to step 616 wherein a 
obtained from memory by the CPU 154 and executed. 25 determination is made as to whether or not there are any 

From step 602 operation proceeds to step 604 wherein the remaining probes from which data needs to be collected. If 

stored information, included in table 169 about the probes „ e are P robes remaining, from which data has not been 

present in the network and the network traffic data table ejected, operation proceeds from step 616 to step 606 

format to be used with each probe, is accessed. Thus, the therein the process of collecting network traffic data from 
data collection and conversion routine 600 obtains from 30 If D !. Xt probe . commen «s. 

memory a list of probes that were detected during the * however, in step 616 it is determined that there are no 

previously discussed initialization process and information P°. rc probes from which data needs to be collected, e.g., it 

on the data table which the probe is to supply to the data * determmed that network traffic data has been collected, 

collection routine. processed and placed in the buffer for each of the probes 

Steps 606 through 614 are used to collect and process ld entified in table 169, operation proceeds to step 618 

network traffic data corresponding to each individual probe wh erem the data collection and conversion routine 600 is 

that was detected during the initialization process. stopped. 

In routine 600, operation proceeds from step 604 to step c point m time » ^ buffer 173 includes data tables 

606. In step 606 the processor 154 requests that the probe . each ldentified Pr° be ^7, 137, 147 corresponding to the 

from which data is to be collected, supply the network traffic JUS * ^P 1 .^ data collection cycle, 

data to the processor using the table format which was 40 y time tne data ejection and conversion routine 600 

associated with the probe in the probe information/data table f ° ps ' ? ata from each of the network traffic probes 127, 137, 

169. 147 will have been converted, as required, into the common 

In step 608, the requested network traffic data table is fo rmat used by the system of the present invention and 

received from the probe. The processing performed on the st ° re ? in . the bufler 173 - ^ buffere d network traffic data 
received network traffic data table to place it into the 45 existin S 10 a common format may then used, e.g., in the 

common data format used in accordance with the present subse q u ent generation of a database of network traffic infor- 

invention depends on the type of data table received. ma Ji° n ' 

If in step 609 an alMatrixTopN(Terminal Count Mode) ™ e data colleclioD a nd conversion routine 600 may be 

table is received, no format conversion operations are re-executed, each time it is desired to collect network traffic 
required. Accordingly, when an alMatrixTopN(Terminal 50 ata ' 1 e ; g *' Pe nodicall y at 30 minute or hourly intervals. To 

Count Mode) table is received operation proceeds from step sunpllf y absolute count data to delta count data conversion, 

608 directly to step 614 wherein the received data table, ir \ one embodiment > the period between data collections is 

including time stamps indicating the time at which the selected to match the period for which the delta count is to 

network traffic occurred, is stored in a buffer 173 included in generated, i.e., lhe delta count represents the network 

memory 162. traffic detected since the last time the network traffic data 

If in step 608 an alMatrixTopN(AllCount Mode) table is 55 tab ^ wa s retrieved, 

received, the data needs to be converted to terminal count . 1S an addltl °nal illustration showing how 

mode to place it in the common format before storage in the received probe data, in the form of a network traffic data 

buffer. In such a case, operation proceeds from step 608 to table » ^ processed by the data collection and conversion 

step 610. In step 610 AUCount Mode data is converted to routine 600 to generate a network traffic data table 640 in the 

terminal mode count data. Once the conversion to terminal 60 de sired common data format (with the nlMatrixTopN and 

count mode data is completed the resulting data table is nlMatrix tables of course lacking the desired but unavailable 

stored in the buffer 173. application layer information). The five possible input data 

If in step 609 an alMatrix table is received, the absolute tables 621, 622, 623, 624 and 625 are shown on the left side 

count data included therein needs to be converted to delta of FIG. 6B. The ovals 630 and 632 represent terminal count 

count data and all mode count data needs to be converted to 65 conversion and delta generation operations, respectively As 

terminal count mode data to place it in the common format illustrated, the alMatrixTopN(Terminal Count Mode) and 

betore storage in the buffer. In such a case, operation nlMatrixTopN data tables are already in the desired common 
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format. Thus, conversion operations need not be performed 
on input tables 621 and 625. 

However, to place the alMatrixTopN(All Count Mode) 
data 622 in the common data format the terminal count 
conversion operation 630 is performed. 

To place alMatrix data 623 in the common data format, 
both the delta generation operation 632 and the terminal 
count conversion operation 630 are performed. 

To place nlMatrix data 624 into the common data format 
the delta generation operation 632 is performed. 

Thus, by performing delta generation operations and/or 
terminal count conversion operations, it is possible to con- 
vert data tables 622, 623, and 624 into the desired common 
data format. 

In accordance with an exemplary embodiment of the 
present invention, the conversion of absolute count data to 
delta count data may be performed in accordance with the 
following eQemplary pseudo code: 
Begin {delta count generation operation} 
if the received data is the first set of data received from the 
probe: 
Begin if 

Store the data table received from the probe in the 
temporary data table storage location associated 
with the specific probe from which the data being 
processed was collected; 
use the data included in the data table as delta data; 
end if 
else 
Begin else 

retrieve the previously stored data table from the 
temporary data table storage location associated 
with the specific probe from which the data table 
being processed was collected; 

store the most recently collected data table in said 
temporary data table storage location; 

from the entries in each row of the most recently 
collected data table, subtract the corresponding 
packet and byte counter values obtained from the 
corresponding row of the table retrieved from said 
temporary data table storage location, the resulting 
packet and byte counters being the delta count 
values for the network traffic table being gener- 
ated; and 

incorporate the generated delta count values in the 
network traffic data table upon which the conver- 
sion operation is being performed thereby replac- 
ing the absolute count values from which they 
were generated, 

discard the network traffic data table retrieved from 
said temporary storage location; 
end else 

end {delta count generation operation} 

In the pseudo code set forth above, the delta time interval 
is the time interval between generation of the retrieved 
tables by the probe which supplies the data being processed. 

As an example of a delta count conversion operation 
consider that a counter in a table corresponding to a specific 
probe had a value of 100 the first time the data table was 
retrieved from the specific probe, a value of 400 the next 
time the data table was retrieved from the same probe and a 
value of 600 the third time data was retrieved from the 
probe. In such a case, the delta counter value generated in 
accordance with the conversion process of the present 
invention for the interval corresponding to the time period 
between the first and second probe data retrievals would be 
300 and the delta counter value generated for the second 
time interval corresponding to the period of time between 
the second and third probe data retrievals would be 200. 
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The conversion of all mode count data to terminal mode 
count data is required to convert data from alMatrix and 
alMatrixTopN (All Count Mode) tables into the common 
format used by the apparatus of the present invention. The 
conversion process of the present invention assumes that the 
data in the tables has already been converted into delta count 
values if it was not already in delta count format. 

In accordance with the exemplary embodiment of the 
present invention, the conversion of all count mode data to 
terminal count mode data in step 610 and the terminal count 
conversion operation 630, involve performing the steps set 
forth in the following pseudo code: 
Begin {conversion of All Count mode data 
to Terminal Count mode Data} 

For each individual conversation for which there is data in 
the data table being processed do: 
Begin {do} 

determine the protocol hierarchy for the individual 

conversation; 
Starting at the network-layer protocols, subtract the 
counter values for each immediate (existing) child 
protocol from the child protocol's immediate 
(existing) parent counter value and store the result 
as the parent protocol's terminal count counter 
value. 

Repeat the preceding step for each child protocol 
until the entire protocol hierarchy has been tra- 
versed. 
End {do} 

end {Conversion of All Count mode data to Terminal 
Count mode Data} 

AS an example of a terminal count conversion operation 
consider the exemplary protocol hierarchy discussed above 
in regard to FIG. 3. In order to convert all count mode data 
to terminal count mode data the following steps would be 
performed assuming the FIG. 3 protocol hierarchy: 

1. The protocol hierarchy for the monitored conversation 
would be determined. 

2. Start with the IP protocol counter values (packet and 
byte counter values). Subtract the corresponding 
counter values for the IPyTCP and IP/UDP/SNMP child 
protocols, from the IP parent protocol counter values. 
Note that the IP/UDP/SNMP protocol is considered to 
be an immediate child of the IP protocol because the 
IP/UDP protocol does not exist in the data retrieved 
from the probe in the FIG. 3 example (since the probe 
is not monitoring it), and so this makes IP the imme- 
diate (existing) parent of IP/UDP/SNMP. Store the 
resulting values as the terminal count IP protocol 
counter values. 

3. Next, move onto the children of IP, namely IPyTCP and 
IP/UDP/SNMP. For IP/TCP, subtract counter values for 
the IP/TCP/FTP and IPyTCP/HTTP protocols from the 
corresponding IP/TCP counter values. Store the result 
as the IP/TCP terminal count counter values. For 
IP/UDP/SNMP there are no children, and so no pro- 
cessing to convert the counter values to terminal count 
values needs to be done. 

4. Finally, the conversion process moves onto the children 
of IP/TCP, namely IP/TCP/FTP and IP/TCP/HTTP. As 
neither of these protocols have children in the hierarchy 
there is no processing to be done to convert the counter 
values to terminal count values. 

Examples of the data collection, conversion (where 
required), and storage processes of the present invention will 
now be discussed. The following examples of how various 
packets and bytes seen for a single conversation would be 
counted in the various probe table formats, are based on the 
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same contrived example conversation. The byte and packet 
counts for the example conversation, for one exemplary 
monitored time period, are set forth below in Table 1. In 
accordance with the present invention, the time period 
would correspond to the time period for which al and nl 
MatrixTopN tables were configured. 

In the following example conversation, in the monitored 
time interval reflected in Table 1, the device with the IP 
address 123.45.67.89 was talking to the device with IP 
address 98.76.54.32 and the listed packet and byte counts 
were seen by a probe in regard to the conversation. 

TABLE 1 



ao 



Protocol 


Packets 


Bytes 


DP 


50 


5000 


TP/TCP 


20 


4000 


IP/TCP/FTP 


200 


30000 


rp/TCp/irrrp 


10 


1000 


IP/UDP/SNMP 


120 


10000 



20 



25 



The byte and packet counts for the example conversation 
shown in Table 1 include only the monitored protocols 
which were shown in the example hierarchy discussed 
earlier in regard to FIG. 3. Note that Table 1 reflects that the 
monitoring of UDP protocol has been turned off in the probe 
monitoring the conversation. Also note that in Table 1, e.g., 
IP/TCP represents all those packets which could only be 
decoded by the probe as far as the IP/TCP protocol— the 
I P/TC P count does not include the IP/TCP/FTP or IP/TCP/ ™ 
HTTP counts. 

Examples of the processing performed in FIG. 6B for 
each of the five possible input table formats will now be 
provided based on the above discussed exemplary conver- 
sation. 

1. alMatrixTopN(Terminal Count Mode) Table Processing 
Example 

As discusned above, the alMatrixTopN (Terminal Count 
Mode) table monitors conversations at all the known 
application-layer protocols, and stores them, using delta 
counters, in a table which is ordered by the packet or byte 
counters (depending upon user-configuration). The counters 
in the alMatrixTopN (Terminal Count Mode) table work in 
Terminal Count Mode, and so a monitored packet incre- 
ments only the counter of the "highest-level" protocol used 
in the packet. 

In this example, we will assume that the user (or client 
program) has requested that the table be ordered by the byte 
counters. As the counters in this table work in Terminal 
Count Mode, the 200 IP/TCP/FTP packets, for example, 
increment only the IP/TCP/FTP packet counter by 200. 

As a result, the alMatrixTopN(Terminal Count Mode) 
table for the exemplary conversation of TABLE 1 would 
look like this: 
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Note that as this is a MatrixTopN table, the packet and 
byte counter values are the total number of packets and bytes 
for the conversation in the monitored time interval. 

For alMatrixTopN(Terminal Count Mode), the counters 
are already delta values in terminal count mode so the table, 
e.g., Table 2, received from a probe, is automatically in the 
common data format. Accordingly, in accordance with FIG. 
6B the alMatrixTopN(Terminal Count Mode) table would be 
stored, unmodified, in the buffer 173. 
2. a!MatrixTopN(All Count Mode) Table Processing 
Example 

The alMatrixTopN (All Count Mode) table monitors 
conversations at all the known application-layer protocols, 
and stores them, using delta counters, in a table which is 
ordered by the packet or byte counters (depending upon 
user-configuration). The counters in the alMatrixTopN (All 
Count Mode) table work in All Count Mode, and so a 
monitored packet increments the counters for all the proto- 
col layers used in the packet. 

Since the alMatrixTopN (All Count Mode) table works in 
All Count Mode, the monitored protocols increment the 
following counters for the exemplary conversation: 



TABLE 3 





Incremented 


Protocol 


Counters 


IP 


IP 


iPyTCP 


IP 




IP/TCP 


IP/TCP/FTP 


IP 




IP/TCP 




[P/TCP/FTP 


IP/TCP/HTTP 


IP 




IP/TCP 




IP/TCP/HTTP 


IP/UDP/SNMP 


IP 




IP/UDP/SNMP 



This means that, for example, the 200 IP/TCP/FTP pack- 
ets increment the IP, the IP/TCP and the IP/TCP/FTP packet 
counters by 200. 

Note that as the IP/UDP protocol is not being monitored 
in this example by the probe, an IP/UDP counter is not 
maintained. Accordingly, packets for the IP/UDP/SNMP 
protocol do not increment an IP/UDP counter. 

In this example, we will assume that the user (or client 
program) has requested that the table be ordered by the byte 
counters, Since the counters work in All Count Mode, the 
200 IP/TCP/FTP packets increment the IP, the IP/TCP and 
the IP/TCP/FTP packet counters by 200. 

The resulting alMatrixTopN(All Count Mode) table 
would look like this: 



TABLE 2 



Network 



Layer 
Protocol 


Source Address 


Destination 
Address 


Application Layer 
Protocol 


Packets 


Bytes 


IP 


123.45.67.89 


98.76.54.32 


IP/TCP/FTP 


200 


30000 


IP 


123.45.67.89 


98.76.54.32 


IP/UDP/SNMP 


120 


10000 


IP 


123.45.67.89 


98.76.54.32 


IP 


50 


5000 


IP 


123.45.67.89 


98.76,54.32 


IP/TCP 


20 


4000 


IP 


123.45.67.89 


98.76.54.32 


IP/TCP/HTTP 


10 


1000 
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TABLE 4A 



Network 

Wer Destination 
Protocol Source Address Address 



Application Layer 

Protocol Packets Bytes 



IP 
IP 
IP 

rp 
ip 



123.45.67.89 
123.45.67.89 
123.45.67.89 
123.45.67.89 
123.45.67.89 



98.76.54.32 
98.76.54.32 
98.76.54.32 
98.76.54.32 
98.76,54.32 



IP 
IP/TCP 
IP/TCP/FTP 
IP/UDP/SNMP 
IP/TCP/mTP 



400 
230 
200 
120 
10 



50000 
35000 
30000 
10000 
1000 



As this is a MatrixTopN table, the packet and byte counter 
values are the total number of packets and bytes for the 
conversation in the monitored time interval. 15 

In order to place the alMatrixTopN(All Count Mode) 
table in the selected common format used by the present 
invention, a terminal count conversion operation is per- 
formed on the values in TABLE 4A as follows; 



TABLE 4B 



Protocol 
IP 



IP/UDP/SNMP 
IP/TCP 



IP/TCP/FTP 
IP/TCP/HTTP 



Formula 


Packets 


Bytes 


IP - IP/UDP/SNMP - 


400 - 230 - 


50000 - 10000 - 


ip/tcp 


120- 


35000 - 




50 


5000 


IP/UDP/SNMP 


- 120 


= 10000 


IP/TCP - IP/TCP/FTP 


230 - 200 - 


35000 - 30000 - 1000 - 


- IP/TCP/HTTP 


10 - 


4000 




20 




IP/TCP/FTP 


-200 


-30000 


IP/TCP/HTTP 


- 10 


• 1000 



now^^ 35 -rce and destination addresses, and 

format, giving the following ; table application-layer protocol. The counters in the alMatrix 

table work in All Count Mode, and so a monitored packet 

TABLE 4C 



Network 

Lay" Destination 
Protocol Source Address Address 



Application Layer 

Protocol Packets 



Bytes 



IP 
IP 
IP 
IP 
IP 



123.45.67.89 
123.45.67.89 
123.45.67.89 
123.45.67.89 
123.45.67.89 



98.76.54.32 
98.76.54.32 
98.76.54.32 
98.76.54.32 
98.76.54.32 



IP 
IP/TCP 
IP/TCP/FTP 
IP/TCP/HTTP 
IP/UDP/SNMP 



50 
20 

200 
10 

120 



5000 
4000 

30000 
1000 

10000 



Since the monitored probe data is now in the desired 
common format, Table 4C is ready for storage in buffer 173. 
3. alMatrix Table Processing Example 

The alMatrix table monitors conversations at all the 
known application-layer protocols, and stores them, using 
absolute counters, in a table which is ordered by network- 



increments the counters for all the protocol layers used in 
the packet. 

Since the alMatrix table works in All Count Mode, the 
monitored protocols increment the counters illustrated in 
Table 3. 

As a result, the alMatrix table would look like this: 



TABLE 5A 



Network 

u y« Destination 



Application Layer 



Bytes 



Protocol Source Address Address Protocol Packets 

IP 123.45.67.89 98.76.54.32 IP 1200 150000 

IP 123.45.67.89 98.76.54.32 IP/TCP 690 1000000 

IP 123.45.67.89 98.76.54.32 IP/TCP/FTP 600 90000 
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TABLE 5A-continued 



Network 












Layer 




Destination 


Application Layer 






Protocol 


Source Address 


Address 


Protocol 


Packets 


Bytes 


IP 


123.45.67.89 


98.76.54.32 


IP/TCP/HTTP 


30 


3000 


[P 


123.45.67.89 


98.76.54.32 


IP/DDP/SNMP 


360 


30000 



10 

Assuming the previously retrieved alMatrix Table from 
the same probe, was as follows: 



TABLE 5B 

Network 



Layer 
Protocol 


Source Address 


Destination 
Address 


Application Layer 
Protocol 


Packets 


Bytes 


IP 


123.45.67.89 


98.76.54.32 


IP 


800 


100000 


EP 


123.45.67.89 


98.76.54.32 


IP/TCP 


460 


965000 


IP 


123.45.67.89 


98.76.54.32 


IP/TCP/FTP 


400 


60000 


IP 


123.45.67.89 


98.76.54,32 


IP/TCP/HTTP 


20 


2000 


IP 


123.45.67.89 


98.76.54.32 


IP/UDP/SNMP 


240 


20000 



For the alMatrix Table 5A, the counter values are absolute 
values presented in all count mode. Accordingly, to place the 
alMatrix Table 5A into the desired common format, the 
counter values must be converted to delta values and all 30 
count mode values need to be converted to terminal count 
mode values. 



the counter values in the alMatrix Table 5B, which was 
received during the last collection operation, from the cor- 
responding counter values found in the most recently 
received alMatrix Table 5A. Table 5B may be obtained from 
the temporary data table storage located in memory 169. The 



TABLE 5C 

Network 



Layer 




Destination 


Application Layer 






Protocol 


Source Address 


Address 


Protocol 


Packets 


Bytes 


IP 


123.45.67.89 


98.76.54.32 


IP 


400 


50000 


IP 


123.45.67.89 


98.76.54.32 


IP/TCP 


230 


35000 


IP 


123.45.67.89 


98.76.54.32 


IP/TCP/FTP 


200 


30000 


IP 


123.45.67.89 


98.76.54.32 


IP/TCP/HTTP 


10 


1000 


IP 


123.45.67.89 


98.76.54.32 


IP/UDP/SNMP 


120 


10000 



After delta count conversion, the values in Table 5C still 
need to be put into terminal count mode. Terminal count 

In accordance with the present invention the first step is 
the generation of delta values. This is done by subtracting 



resulting table, Table 5C, which includes the delta values 
generated by the subtraction operation is shown below: con- 
version involves performing the subtractions shown in 
Table 5D. 



TABLE 5D 



Protocol 


Formula 


Packets 


Bytes 


IP 


IP - IP/UDP/SNMP - 


400 - 230 - 


50000 - 10000 - 




IP/TCP 


120 = 


35000 - 






50 


5000 


IP/UDP/SNMP 


IP/UDP/SNMP 


-120 


- 10000 


IP/TCP 


IP/TCP - IP/TCP/ETP 


230 - 200 - 


35000 - 30000 - 1000 - 




- IP/TCP/HTTP 


10 - 


4000 






20 




IP/TCP/PTP 


IP/TCP/FTP 


-200 


- 30000 


IP/TCP/HTTP 


IP/TCP/HTTP 


- 10 


= 1000 



08/05/2002, EAST version: 1.03.0002 



US 6,327,620 Bl 
23 24 

The terminal count conversion operation results in the involves subtracting the counter values from the current 
following table: nlMatrix Table 7A from the corresponding counter values in 



TABLE 5E 

Network 



Layer 




Destination 


Application Layer 






Protocol 


Source Address 


Address 


Protocol 


Packets 


Bytes 


IP 


123.45.67.89 


98.76.54.32 


IP 


50 


5000 


IP 


123.45.67.89 


98.76.54.32 


IP/TCP 


20 


4000 


IP 


123.45.67.89 


98.76.54.32 


IP/TCP/FTP 


200 


30000 


IP 


123.45.67.89 


98.76.54.32 


IP/TCP/HTTP 


10 


1000 


IP 


123.45,67.89 


98.76.54.32 


IP/UDP/SNMP 


120 


10000 



As Table 5E is now in the common data format, i.e., with 
counter values expressed as delta counter values in terminal 
count mode, Table 5E can be stored in the buffer 173. 
4. nlMatrixTopN Table Processing Example 

The nlMatrixTopN table monitors conversations at the 
network-layer protocols only, and stores them, using delta 
counters, in a table which is ordered by the packet or byte 
counters (depending upon user-configuration). 

The nlMatrixTopN table monitors only network-layer 
protocols, and so will consider all of the packets given in the 
exemplary conversation to be IP packets, and so the stored 
table would be as follows: 



TABLE 6 



Protocol 


Source Address 


Destination Address 


Packets 


Bytes 


IP 


123.45.67.89 


98.76.54.32 


400 


50000 













Note that as this is a MatrixTopN table, the packet and 
byte counter values are the total number of packets and bytes 35 
for the conversation in the monitored time interval. Since the 
counter values in the nlMatrixTopN table are already delta 
counter values, no conversion processing needs to be per- 
formed on the nlMatrixTopN table and it is ready for storage 
in the buffer 173 as retrieved. 40 
5. nlMatrix Table Processing Example 

The nlMatrix table monitors conversations at the network- 
layer protocols only. It stores the counted byte and packet 
information, using absolute count values, in a table which is 
ordered by network-layer protocol and source and destina- 45 
tion addresses. 

As the nlMatrix table monitors only network-layer 
protocols, it will consider all of the packets given in the 
example conversation to be IP packets, and so the stored 
table would look like this: « 0 



TABLE 7A 



Protocol 


Source Address 


Destination Address 


Packets 


Bytes 


IP 


123.45.67.89 


98.76.54.32 


1200 


150000 



Assuming the most recent previously retrieved nlMatrix 
Table from the same probe was as follows: 



TABLE 7B 



Protocol 


Source Address 


Destination Address 


Packets 


Bytes 


IP 


123.45.67.89 


98.76.54.32 


800 


10000 



65 

In order to place the nlMatrix table in the desired common 
format, a delta conversion operation is performed. This 



the previously received Table 7B to generate a table as 
follows: 



TABLE 7C 



Protocol 


Source Address 


Destination Address 


Packets 


Bytes 


IP 


123.45.67.89 


98.76.54.32 


400 


50000 



Since Table 7C is now in the desired common format with 
delta counter values, it is ready for storage in the buffer 173. 

As the result of the data collection and conversion rou- 
tines discussed above, the data placed in the buffer 173 is in 
the common format rendering it suitable for use, e.g., in 
generating a network traffic database. 

FIG. 7 illustrates how the network traffic data 701, 703, 
705, from the first through third probes respectively, placed 
in the buffer 173, can be used to generate a network traffic 
database 707. In accordance with one embodiment of the 
present invention, the network traffic data 701, 703, 705 is 
processed by a database generation and maintenance routine 
700 to generate a database 707. Unlike prior art databases 
which do not include data sets of different resolutions which 
overlap in time, the database 707 includes multiple resolu- 
tions of the same data in parallel, e.g., in hourly, 6 hourly, 
daily, and weekly data sets. These data sets are stored in 
corresponding FIFO data structures 709, 711, 713, 715, 
respectively. The database 707 may be stored on the data 
storage device 158. 

The parallel, multi-resolution storage method of the 
present invention provides a relatively simple means of 
managing a network traffic database and limiting its size 
without the need for an aging process and the double 
buffering often associated with such processes. 

While the amount of processing required to create and 
maintain multiple parallel sets of data in different resolutions 
may be slightly greater than systems which do not use 
parallel data sets, the processing associated with creating 
such a database is more constant than systems which involve 
aging processes. This is because the periodic load associated 
with the aging process is avoided when using the method of 
the present invention. A further benefit of this scheme is that 
the different resolutions of data are readily available which 
makes switching between different data resolutions fast and 
efficient when displaying data and or responding to admin- 
istrator queries. 

In the exemplary embodiment of FIG. 7, the disk space 
allocated to the database 707 is divided into 4 parts and 
assigned to the following fixed resolutions: hourly, 6-hourly, 
daily and weekly. As discussed above each row of a data 
table 701, 703, 705 corresponds to a monitored conversation 
and includes byte and packet count information. Time stamp 
information indicating the time the conversation was moni- 
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tored is also included in the tables 701, 703, 705. As each 
row of data is read in from one of the tables 701, 703, 705, 
it is used to create or update an entry in each of the parallel 
data sets 709, 711, 713, 715. Within the generated parallel 
data sets, each record is used to represent a conversation 5 
between two hosts and the records are time aligned depend- 
ing on the resolution: hourly on the hour; 6-hourly at 0600, 
1200, 1800 and 2400 hrs; daily at 2400 hrs; and weekly at 
2400 hrs on Saturday. Database records for the same time 
interval can be considered as being in the same "bucket". 
Thus, a bucket is a set of data storage records for storing 10 
network traffic data corresponding to the preselected unit of 
time used for the resolution to which the bucket corresponds, 

FIG. 8 illustrates the database generation and mainte- 
nance routine 700 of the present invention in greater detail. 
The illustrated routine 700 may be one of the parallel data 15 
set generation routines 166 stored in the management sta- 
tion's memory 162. 

The routine 700 beings in step 702 wherein the database 
generation routine is started, e.g., by having the CPU 154 
load and begin executing the routine 700. In embodiments 20 
where the routine 700 is implemented using parallel 
processing, it may be loaded into, and executed by the CPU 
155 at the same time it is being loaded and executed by the 
CPU 154. In a parallel processing embodiment, the different 
CPUs 154, 155 are normally responsible for creating and 25 
maintaining, in parallel, data sets of different resolutions. 
For example, CPU 154 may be responsible for creating and 
maintaining the hourly and 6 hour network traffic data sets 
while the CPU 155 might be responsible for creating the 
daily and weekly network traffic data sets. 30 

For the sake of simplicity the following discussion will 
assume that the routine 700 is executed by the processor 
154. However, it is to be understood that, as discussed 
above, multi-processor implementations are possible. 

Operation proceeds from step 702 to step 704 wherein the 35 
CPU 154 creates hourly, 6 hour, daily and weekly FIFO data 
structures, one for each of the different data set resolutions 
to be supported. Step 704 may involve, e.g., allocating data 
storage records to serve as buckets. For example, the hourly 
FIFO would comprise a plurality of buckets each corre- 40 
sponding to a one hour period of time. Each bucket may 
include several records or entries each corresponding to a 
different conversation/protocol pair. The daily FIFO would 
comprise a plurality of buckets each corresponding to a 
different one day period of time. As will be discussed below, 45 
as time progresses, each bucket in the FIFO is filled. When 
all the records in the FIFO are filled, the records in the oldest 
buckets are overwritten thereby insuring that the process can 
continue after the available storage space is used. 

Once the FIFO data structures are created in step 704, 50 
operation proceeds to step 706. In step 706, the buffer 173 
into which collected network traffic data is placed, is moni- 
tored for network traffic data. Upon detecting that network 
traffic data has been placed into buffer 173, operation 
proceeds to step 708. In step 708 the time stamps associated 55 
with the buffered data are examined. In step 710, the 
buffered network traffic data is assigned to be included in 
individual buckets in the FIFO structures as a function of the 
examined time stamps. Thus, data is placed in buckets, e.g., 
sets or groups of records corresponding to the basic unit of 60 
time supported, as a function of time stamps indicating the 
time period in which the network traffic was monitored. 
Accordingly, data collection and reporting delays encoun- 
tered by the management station 150 do not negatively 
impact the accuracy of the created network traffic database. 65 

Steps 712, 714, 716, 718 which are illustrated in parallel 
represent the updating of records included in the hourly, six 



,620 Bl 

26 

hourly, daily and weekly FIFO data structures, respectively, 
using the same set of network traffic data. Steps 712, 714, 
716, 718 are illustrated in parallel to show that they may be 
performed in parallel by one or more CPUs 154, 155. 

Operation proceeds from steps 712, 714, 716 and 718 to 
step 720 wherein the data obtained from the buffer 173, used 
to update the hourly, six hourly, daily and weekly data 
records, is deleted. Operation then returns to monitoring step 
706 so that the database updating process will be performed 
on a continuous basis until, e.g., the management station 150 
is powered off or reset. 

As a simple example of the generation of the hourly and 
6 hourly data sets, consider hosts A through F illustrated in 
FIG. 2 as computers 21, 22, 23, 31, 32, 33, respectively. The 
boxes in FIG. 9 represent database records created from 
traffic between hosts A through F. Dashed lines are used to 
indicate different hourly time periods 901, 902, 903, 904, 
905, 906 and a single 6 hourly time period 910. In FIG. 9, 
the range of numbers at the top of each time period is used 
to indicate the specific hour or hours included in the time 
period, the first and second letters in each box indicate the 
two hosts involved in the monitored conversation. In 
addition, the number in the box indicates the number of 
packets exchanged between the indicated hosts during the 
indicated time period. 

The first hourly time period, beginning at hour 0 and 
ending at hour 1, corresponds to bucket 901. Two conver- 
sations were detected during this first hourly time period. A 
first conversation between devices A and B which involved 
10 packets and a second conversation between devices A and 
E which involved 6 packets. The number of bytes, in 
addition to the number of packets, may also be stored in each 
record of the database 707. 

A Note that over a 6-hour period, the hourly resolution 
data set 920 has six "buckets", 901 through 906, correspond- 
ing to first through sixth hourly time periods and the 
6-hourly data set has one bucket 910 corresponding to the 
single 6 hour time period. Note also that the 6-hour bucket 
910 has more conversations and thus more entries than any 
one of the individual hourly buckets 901 through 906. 
However, the records in the six hour data set 922 are of a 
lower resolution than the hourly data set 920, since they do 
not include detailed hourly conversation data. 

In accordance with one embodiment of the present 
invention, read access is limited to complete data records. 
Thus, data in a given time period may not be accessed until 
the record is fully complete, i.e., all the data from the system 
probes for the given time period has been included in the 
data record. By restricting access to completed data records, 
the presentation of incomplete data counts to an application 
or system user is avoided. In other embodiments, up to the 
minute data records are made available to the user. In such 
embodiments, a user may review, e.g., the most recent data 
in the weekly database despite the fact that the collection of 
the data for the current week is not yet complete. 

As discussed above, as the data at a resolution fills the part 
of the storage space assigned to that particular resolution, the 
data structure used to store the data records at the particular 
resolution operates as a FIFO data structure. Accordingly, 
the oldest database records corresponding to the data set of 
the particular resolution will be reused to store new data. The 
hourly data set tends to be the first resolution to hit the 
database size limit when the available storage space for the 
database 707 is equally divided amongst the four supported 
resolutions since it grows the fastest. However, given limited 
available storage space, all the resolutions will reach their 
limit given sufficient operating time. FIG. 10 illustrates an 
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exemplary steady station condition that may be reached after 
7 weeks of operating one exemplary system 200. Note that 
in the FIG. 10 example, the database includes enough 
storage space to store hourly information for 1.5 days, 
6-hourly information for 4.5 days, daily information for 9 5 
days and weekly information for 7 weeks assuming the use 
of the same amount of storage for each of the different 
resolutions. Note that the actual time periods for a given 
system will depend on the number of conversations which 
are monitored and the actual amount of storage space 
allocated for the database 707. 
What is claimed is: 

1. A method of using network traffic data probes in a 
computer network including said network traffic data 
probes, the method comprising the steps of: 

detecting network traffic data probes in the computer 15 
network; 

controlling at least some of the detected network traffic 
data probes to collect and store network traffic data in 
one of a plurality of network traffic data table formats, 
the data table format being used with at least one 20 
individual controlled probe being the one of the plu- 
rality of data table formats that is supported by the 
individual controlled probe that is closest to and dif- 
ferent from a preselected common network traffic data 
format wherein the common preselected data format 
includes delta count values and terminal count mode 25 
values; and 

periodically retrieving, from each individual controlled 
probe, network traffic data collected by the individual 
controlled probe. 

2. The method of claim 1, wherein the step of controlling 30 
at least some of the detected network traffic data probes to 
collect and store network traffic data in one of a plurality of 
network traffic data table formats includes the step of: 

selecting a network traffic data table format which 
includes application layer information over a network 35 
traffic data table format that includes only network 
layer information. 

3. A method of using network traffic data probes in a 
computer network including said network traffic data 
probes, the method comprising the steps of: 

detecting network traffic data probes in the computer 40 
network, wherein the network traffic probes are 
RMON2 probes; 

controlling at least some of the detected network traffic 
data probes to collect and store network traffic data in 
one of a plurality of network traffic data table formats, 45 
the data table format being used with each individual 
controlled probe being the one of the plurality of data 
table formats that is supported by the individual con- 
trolled probe that is closest to a preselected common 
network traffic data format, said controlling including 
selecting a network traffic data table format which 50 
includes application layer information over a network 
traffic data table format that includes only network 
layer information, and delta count values over a net- 
work traffic data table format that includes absolute 
count values; and 55 

periodically retrieving, from each individual controlled 
probe, network traffic data collected by the individual 
controlled probe. 

4. The method of claim 3, wherein the step of controlling 

at least some of the detected network traffic data probes to 60 
collect and store network traffic data in one of a plurality of 
network traffic data table formats further includes the step 
of: 

selecting a network traffic data table format which 
includes terminal count mode values over a network 65 
traffic data table format that includes all count mode 
values. 



5. A method of using network traffic data probes in a 
computer network including said network traffic data 
probes, the method comprising the steps of: 

detecting network traffic data probes in the computer 
network, wherein the network traffic data probes are 
RMON2 probes; 

controlling at least some of the detected network traffic 
data probes to collect and store network traffic data in 
one of a plurality of network traffic data table formats, 
the data table format being used with at least one 
individual controlled probe being the one of the plu- 
rality of data table formats that is supported by the 
individual controlled probe that is closest to preselected 
common network traffic data format, said controlling 
including selecting a network traffic data table format 
which includes delta count values over a network traffic 
data table format that includes absolute count values; 
and 

periodically retrieving, from each individual controlled 
probe, network traffic data collected by the individual 
controlled probe. 

6. A method of using network traffic data probes in a 
computer network including said network traffic data 
probes, the method comprising the steps of: 

detecting network traffic data probes in the computer 
network, wherein the network traffic data probes are 
RMON2 probes; 

controlling at least some of the detected network traffic 
data probes to collect and store network traffic data in 
one of a plurality of network traffic data table formats, 
the data table format being used with each individual 
controlled probe being the one of the plurality of data 
table formats that is supported by the individual con- 
trolled probe that is closest to a preselected common 
network traffic data format, said controlling including 
selecting a network traffic data table format which 
includes terminal count values over a network traffic 
data table format that includes all count values; and 

periodically retrieving, from each individual controlled 
probe, network traffic data collected by the individual 
controlled probe. 

7. A method of using network traffic data probes in a 
computer network including said network traffic data 
probes, the method comprising the steps of: 

detecting network traffic data probes in the computer 
network, wherein network traffic data probes are 
RMON2 probes; 

controlling at least some of the detected network traffic 
data probes to collect and store network traffic data in 
one of a plurality of network traffic data table formats, 
the data table format being used with each individual 
controlled probe being the one of the plurality of data 
table formats that is supported by the individual con- 
trolled probe that is closest to a preselected common 
network traffic data format, said controlling including 
controlling each individual probe to use one of an 
alMatrixTopN(Terminal Mode), an alMatrixTopN 
(AllMode), an alMatrix, a nlMatrixTopN and a nlMa- 
trix data table format, the utilized data table format 
being selected in the following order or preference: 
alMatrixTopN(Terminal Mode), alMatrixTopN 
(AllMode), alMatrix, nlMatrixTopN and nlMatrix; and 

periodically retrieving, from each individual controlled 
probe, network traffic data collected by the individual 
controlled probe. 

8. A method of using network traffic data probes in a 
computer network including said network traffic data 
probes, the method comprising the steps of: 
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detecting network traffic data probes in the computer 
network; 

controlling at least some of the detected network traffic 
data probes to collect and store network traffic data in 
one of a plurality of network traffic data table formats, 
the data table format being used with each individual 
controlled probe being the one of the plurality of data 
table formats that is supported by the individual con- 
trolled probe that is closest to a preselected common 
network traffic data format; 

periodically retrieving, from each individual controlled 
probe, network traffic data collected by the individual 
controlled probe; and 

processing retrieved network traffic data that is not in the 
preselected common network traffic data format to 
place it in the preselected common network traffic data 
format. 

9. The method of claim 8, 

wherein the plurality of network traffic data formats 
include RMON2 management information base (MIB) 20 
formats, which support counting of network traffic data 
using absolute counter values, 

wherein the preselected common network traffic data 
format includes the use of delta counter values, the step 
of processing retrieved network traffic data comprising 2 5 
the step of: 

converting absolute counter values to delta counter val- 
ues. 

10. The method of claim 9, wherein the step of converting 
absolute counter values to delta counter values includes the 
steps of: 

for each retrieved absolute counter value to be converted, 
subtracting from the absolute counter value to be 
converted a previously retrieved absolute counter value 
to generate a delta counter value. 

11. The method of claim 9, 

wherein the common data format includes the use of 
terminal count mode values for application layer data 
counts, 

wherein at least some of the retrieved network traffic data 
includes all count mode values for application layer 
data counts, the method further comprising the step of: 

converting received all count mode values to terminal 
count mode values. 

12. The method of claim 11, further comprising the steps 

of: 

storing retrieved network traffic data that is in the com- 
mon data format in a buffer; and 

storing retrieved network traffic data that has been con- 
verted to the common data format in the buffer. 

13. The method of claim 12, further comprising the step 

of: 

generating a graphic image representing network traffic 

data using the buffered network traffic data; and 
displaying the graphic image on a display device. 

14. A method of utilizing RMON2 data probes capable of 
supporting a plurality of network traffic data tables in a 
computer network, the method comprising the step of: 

collecting from each of the RMON2 data probes a net- 
work traffic data table including network traffic infor- 
mation; 

processing the contents of each collected network traffic 
data table which does not include network traffic infor- 
mation in a preselected data format to generate a 
network traffic data table in the preselected data format, 
including converting absolute count values to delta 
count values. 
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15. The method of claim 14, further comprising the step 

of: 

converting all count mode values to terminal count mode 
values. 

16. The method of claim 14, wherein the step of collecting 
from each of the RMON2 data probes a network traffic data 
table includes the step of: 

configuring each of the RMON2 data probes which sup- 
port alMatrixTopN(Terminal Count Mode) tables to 
collect network traffic data in an alMatrixTopN 
(Terminal Count Mode) table. 

17. A method of utilizing RMON2 data probes capable of 
supporting a plurality of network traffic data tables in a 
computer network, the method comprising the steps of: 

collecting from each of the RMON2 data probes a net- 
work traffic data table including network traffic 
information, including configuring each of the RMON2 
data probes which support alMatrixTopN(TenninaI 
Count Mode) tables to collect network traffic data in an 
alMatrixTopN(Terminal Count Mode) table; and 

processing the contents of each collected network traffic 
data table which does not include network traffic infor- 
mation in a preselected data format to generate a 
network traffic data table in the preselected data format. 

18. The method of claim 17, further comprising the step 

of: 

generating a graph from at least some of the network 
traffic, data converted into the preselected common data 
format. 

19. A computer network comprising: 

a plurality of network data probes for monitoring network 

data in the computer network; and 
a management station coupled to the network data probes, 

the management station including: 
means for identifying probes in the computer network; 

and 

means for configuring a set of individual identified net- 
work probes to collect network traffic data, each one of 
the set of individual network probes supporting mul- 
tiple network traffic data table formats, at least one of 
the table formats that is supported by individual probe 
which requires the least modification to place the 
collected data in a common preselected data format, 
and is different from the common preselected data 
format, wherein the common preselected data format 
includes delta count values and terminal count mode 
values. 

20. The computer network of claim 19, further compris- 
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means for processing the contents of network traffic data 
tables obtained from probes to generate network traffic 
data tables having the common preselected data format. 

21. A computer network, comprising: 

a plurality of network data probes for monitoring network 
data in the computer network; and 

a management station coupled to the network data probes, 
the management station including: 

means for identifying probes in the computer network; 

means for configuring a set of individual identified net- 
work probes to collect network traffic data, each one of 
the set of individual network probes supporting mul- 
tiple network traffic data table formats, each one of the 
individual probes being configured to collect data in the 
one of the table formats that is supported by the 
individual probe which requires the least modification 
to place the collected data in a common preselected 
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data format, wherein the common preselected data 
format includes delta count values and terminal count 
mode values; 

means for processing the contents of network traffic data 
tables obtained from probes to generate network traffic 5 
data tables having the common preselected data format; 
and 

a storage device for storing absolute counter values 
between data collection operations for subsequent use 
in generating delta count values from absolute counter 
values. 
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22. The computer network of claim 21, further compris- 
ing: 

means for displaying collected network traffic data placed 
in the preselected common data format. 

23. The computer network of claim 21, further compris- 
ing: 

means for printing network traffic data placed in the 
preselected common data format. 

***** 
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